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5 Domaine technique et art anterieur 

L'invention conceme le domaine de 1'architecture de reseaux de 
paquets et la gestion de la qualite de service de ces reseaux. 

10 [.'internet est a vocation multiservice et appele a fournir le 

support pour une large gamme de services et duplications. On distingue 
deux grandes classes de trafic dans ce reseau : le trafic temps reel (ou 
trafic « streaming ») produit en general par les applications audio ou 
• video, et le trafic de donnees (ou trafic elastique) correspondant au 

15 transfer! de documents numeriques. Le trafic temps reel a des exigences 
de qualite de service correspondant au besoin de conservation du signal - 
les variations de debit qui caracterisent le signal produit par la source 
doivent etre preservees lorsque le signal traverse le reseau. La qualite de 
service du trafic de donnees se mesure par le temps de transfer! des 

20 documents. Ce temps, ou de maniere equivalente le debit moyen realise 
lors du transfer!, depend de toute la chaine de communication de la 
source a la destination. Un objectif de qualite de service pour un reseau 
internet pourrait etre de paraitre transparent au trafic de donnees en 
n'introduisant pas de reduction de debit supplemental par rapport aux 

25 limitations introduites ailleurs (serveur, reseaux d'acces, equipement de 
I'utilisateur); dans ce sens le reseau assure la conservation du debit des 
flots de donnees. 

Le reseau internet public offre un service de transport a des 
30 clients utilisateurs dans' un contexte commercial. La question de la 
tarification est done importante. L'architecture de reseau doit permettre 
un retour sur investissement pour I'operateur avec des prix competi'tifs 
pour les services de qualite demandes par les utilisateurs. 

35 Differentes propositions d 'architecture de reseau repondent 

diversement a ces exigences de qualite et de rentabilite. Certaines comme 
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intserv, Diffserv ou MPLS-TE sont normalises tandis que d'autres restent 
proprietaires. 

L'architecture de reseau IP existante, appelee « architecture best 
effort » (ou architecture du « meilleur effort »), n'offre aucune garantie de 
qualite de sen/ice. La performance est rendue satisfaisante par le 
surdimensionnement. La performance depend egalement de la 
cooperation des utilisateurs qui, en principe, doivent regler le debit ^de 
leurs applications en fonction de I'etat de congestion du reseau (grace 
notamment aux protocoles TCP et « TCP-friendly »). Les paquets des 
trafics temps reel et de donnees sont traites sans distinction. 

Les routeurs IP emploient couramment le principe d'un partage 
de charge lorsque deux ou plusieurs chemins sont disponibles pour 
I'acheminement d"un paquet. Le choix pour un paquet donne est 
typiquement determine par Implication d^une fonction « hash » a 
I'adresse IP d'origine du paquet : cette fonction donne comme resultat un 
entier designant Interface en question. Ainsi, la charge est repart.e sur les 
differents chemins tandis que tous les paquets d'un mime flot suivent le 
meme chemin et arrivent done dans le bon ordre. 

La tarification est en general forfaitaire pour les pet.ts 
utilisateurs. En revanche, les gros utilisateurs peuvent payer I'operateur en 
fonction du volume de trafic emis (ou recu). Dans ce cas, il y a en general 
un contrat specifiant les caracteristiques de qualite de service offertes : 
taux de perte de paquets, delai-de traverse, elements de fiabilite. 

Parmi les differentes propositions d'architecture evoluees 
permettant d'ameliorer ('architecture ci-dessus, la plupart utilisent un 
principe de reservation de ressources. Le reseau et I'utilisateur etabl.ssent 
un « contrat de trafic » pour une communication prevue : 

. I'utilisateur annonce la communication prevue en decrivant la 

nature du trafic, 

le reseau affecte si possible les ressources necessaires 

(controle d'admission), # 

; le trafic emis est controle a I'acces afin de verifier quil 

respecte la description prealable (ou les ressources attributes sont 
controlees par un ordonnancement de type WFQ). 
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Selon I'architecture proposee, ce contrat concerne diversement 
un micro-fiot on un agregat de flots, une communication point a point ou 
une communication multipoint. 

La tarification fait partie du contrat. Elle depend en general de la 
5 description de trafic fournie par I'utilisateur qui conditionne Tattribution de 
ressources. 

if 

Dans la differentiation par classe de service, le reseau traite 
d'une maniere specifique tous les paquets appartenant a une meme 
10 classe. On distingue la differentiation entre les deux types de qualite 
necessaires respectivement au trafic temps reel et au trafic de donnees, et 
la differentiation entre niveaux differents de qualite d'un meme type. II 
. est necessaire en general de controler soigneusement I'attribution des 
paquets aux differentes classes de service en respectant les termes d'un 
1 5 contrat entre I'usager et I'operateur portant sur des agregats de trafic. 

La tarification fait partie du contrat. Elle depend en general du:.; 
volume de trafic emis dans chaque classe. II y a necessairement une. 
differentiation de tarif par niveau de qualite car, sinon, chaque utilisateur 
placerait tout son trafic dans la classe de qualite la plus haute. 

20 

L'Internet auto-gere decrit par F.P. Kelly dans " Models for a 
self-managed Internet", Philosophical Transactions of the Royal Society, 
Vol. A358, pages 2335-2348, 2000, evite le recours a la reservation et a 
I'utilisation de classes de service. Dans cette architecture, le reseau emet 

25 en cas de congestion des marques ECN (« Explicit Congestion 
Notification ») munies d'un « cout » unitaire. Les utilisateurs peuvent 
moduler leur « facture » en fonction de leur reaction aux marques 
recues : ils peuvent ainsi ignorer la congestion en ne reagissant pas aux 
marques regues s'ils acceptent de payer davantage pour leur 

30 communication. 

La necessite de distinguer trafic temps reel et trafic de donnees 
est en principe evitee. On pretend rendre negligeable le delai des paquets 
(suffisamment faible pour les flots temps reels) en utilisant I'occupation 
d'une file d'attente virtuelle pour decider le marquage ECN. 
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Le reseau auto-gere ne necessite pas la mise en place d'un 
protocole de signalisation specifique et permet une gestion de ressource 
aussi simple que celie d'un reseau « best effort ». 

5 Dans ^architecture de type « flow-aware networking » (reseau 

avec connaissance des fiots), decrite par exemple par J. Roberts et al. 
dans -« Quality of service by flow-aware networkings Philosophical 
Transactions of the Royal Society, Vol A358, pages 2197-2207, 2000, on 
identifie « au vol » chaque flot utilisateur et on effectue un controle de 

10 trafic sur la base de ces flots. Un flot est un ensemble de paquets ayant 
les memes valeurs dans certains champs invariants de I'entete. Ces 
champs sont typiquement les adresses IP d'origine et de destination, les 
numeros de ports du protocole de transport en IPv4 ou le champs « flow 
label » de IPv6. Un flot peut etre specifie par ces valeurs associees a une 

15 duree d'inactivite (temporisation). Un flot se termine lorsque aucun paquet 
n'est observe pendant cet intervalle d'inactivite. Le principe et les 
elements de cette architecture sont representes en figure 1. Des moyens 4 
assurent une police du debit crete des flots temps reel. Les paquets sont 
ensuite transmis a un module 6 de decision d'acheminement, qui consuite 

20 une liste 10 de flots proteges. II transmet les paquets admis a un module 
8 qui les ordonne selon une file prioritaire. Celle-ci donne priorite aux 
paquets des flots de type « temps reel ». Des donnees 16 de conditions 
d'admissibilite sont envoyees par le module 8 au module 6. II s'agit 
essentiellement d'une estimation du debit cumule actuel des flots temps 

25 ' reel et d'une mesure de la bande passante disponible pour un flot de 
donnees. 

Un controle implicite d'admission est applique pour empecher le 
demarrage de nouveaux flots lorsqu'un lien ou un chemin est 

30 momentanement en etat de congestion. Ce controle a pour objet la 
protection de la qualite de service des flots deja entames. Plusieurs 
propositions pour la realisation d'un controle implicite d'admission sont 
apparues dans la litterature, par exemple dans I'article de A. Kumar et 
al. « Non-intrusive TCP connection admission control for bandwidth 

35 management of an Internet access link», IEEE Comm. Mag. Vol 38, No 5, 
pages 160-167, 2000. 
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Dans I'architecture de la figure 1, on applique une differenciation 
par classe de service pour distinguer trafic temps reel et trafic de donnees. 
Cependant, les conditions d'admission ne dependent ni du type ni des 

5 caracteristiques particulieres de trafic des flots. On evite ainsi le besoin de 
signaler les caracteristiques de trafic des flots. II reste necessaire d'assurer 
a I'acces que le debit crete des flots temps reel ne depasse pas une limite 
preetablie. La connaissance de cette limite est obligatoire pour determiner 
les conditions d'admission (voir I'article de T. Bonald et al. « IP traffic and 

10 QoS control : towards a flow-aware architecture*, Proc. of World Telecom. 
Conf., Paris 2002). 

La tarification dans cette architecture pourrait ne dependre que 
du volume de trafic emis (ou recu) par un client. Tout flot commence est 
15 efficace (car protege) et done redevable. La distinction tempsy 
reel/donnees ne necessite pas une differenciation de tarif car il n'y a pas--: 
d'incitation de substitution : les flots temps reel subissent perte et delau 
negligeables tandis que les flots de donnees ne sont pas limites en debit. 

20 Un autre type d 'architecture de type « flow-aware » est propose 

par la societe americaine Caspian Networks (voir par exemple les 
publications de demandes de brevet US-2002/57699, US-2002/57651 et- 
US-2002/80786). Les flots sont identifies « au vol » comme ci-dessus. 
Avec chaque flot admis, on associe des parametres de qualite de service 

25 et une route. Les parametres de qualite de service sont deduits de 
diverses sources d'informations dont I'entete des paquets et une table de 
specifications deduites du SLA de I'utilisateur. La route est calculee, en 
fonction des parametres de qualite de service et de I'utilisation actuelle 
des ressources du reseau, afin de respecter les exigences de performance 

30. du flot. Les parametres de qualite de service precisent entre autre un 
debit garanti (GR, pour « guaranteed rate »). Un debit disponible (AR, 
pour « available rate ») est attribue au flot pour un certain intervalle de 
temps en fonction de I'etat de congestion de sa route. Cette architecture 
emploie un ordonnancement en entree pour assurer que le debit du flot 

35 respecte le debit attribue (GR + AR). Un ordonnancement en sortie assure 
le respect des exigences de performance (delai par paquet notamment). 
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L'ordonnancement en entree est par espacement avec rejet des paquets 
en trop, et l'ordonnancement en sortie utilise un algorithme de type WFQ 
par flot Le controle d'admission des flots doit etre employe lorsqu'il est 
impossible de trouver une route adequate pour un nouveau flot entrant. 

5 

Les architectures qu'on vient de decrire possedent toutes des 
inconvenients lies, de manieres diverses, a la nature des garanties de 
qualite, a la complexite de mise en oeuvre ou a la rentabilite du reseau. 

10 Les inconvenients d'une architecture de type « best effort » sont 

bien connus : 

- degradation de la performance de toutes les communications 
en cas de congestion, 

delais et pertes de paquet incontroles pour les 
15 communications temps reel en concurrence avec le trafic de donnees, 

partage de bande passante non equitable, notamment si 
certains utilisateurs sont malveillants, 

- cout eventuellement eleve pour assurer la qualite de service 
par surdimensionnement, 

20 - la tarification forfaitaire rend difficile la definition d'un prix 

juste assurant le retour sur investissement lorsque le trafic des utilisateurs 

est tres variable, 

la tarification en fonction du volume de trafic est contestable 

en raison de la sensibilite de'ce dernier a la congestion (renouvellement 
25 de. paquets perdus) et le non respect eventuel d'un niveau de qualite 

minimal occasionnant I'abandon de communications en cours. 

Concernant le principe de reservation, les inconvenients suivants 
apparaissent : 

30 - il s'avere impossible en pratique de decrire le trafic d'une 

communication (a debit typiquement tres variable) de. maniere succincte 

avec des parametres controlables a I'acces, 

la mise en oeuvre de la reservation est complexe, necessitant 

un protocole de signalisation, le maintien de bases de donnees avec les 
35 parametres de chaque communication (appele « state » en anglais) et la 

mise en oeuvre de mecanismes d'ordonnancement. 
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la notion de reservation devient imprecise si le chemin 
emprunte par une communication ne peut pas etre specifie 
(« reservation » pour un ensemble de flux de traf.c a destinations 
differentes dans le cas d'une architecture Diffserv notamment, mstabil.te 

5 du routage IP, ), 

. une garantie stride de qualite de service - dans le « service 
garanti » de Intserv, par exemple - est une solution couteuse en 
ressources, 

- la sur-reservation, communement appliquee pour compenser 
10 le fait que les utilisateurs sur-estiment leur trafic, conduit a une absence 

de garantie reelle, 

. la tarification est problematique : en cas de sur-reservat.on, 

la tarification sur la base des parametres de trafic (du contrat de trafic) 

n'est pas en relation directe avec le cout de la communication (qui depend 

,5 du volume de trafic reellement emis) ; en cas de garantie stncte, une 

tarification en rapport avec la quantite des ressources reservees (bande; 

passante, memoire) risque d'etre prohibitive. 

La differentiation par classe de service introduit d'autres 

20 inconvenients : 

- une absence de garanties de qualite de service quantifiables 

et verifiables pour le trafic de donnees, 

- impossibility de garantir la qualite de service du trafic temps 
reel lorsque le chemin des communications n'est pas fixe, 

, 5 . ia gestion des limites de trafic par classe et par utilisateur 

reste complexe (gestion de SLA, serveurs de « policy », signalisation des 

parametres de trafic, ) 

le trafic a I'interieur d'une classe de faible priorite subit les 
memes inconvenients que le trafic dans une architecture de type « best 
30 effort » (effondrement de la performance en cas de congestion, pas de 
protection contre les usagers malveillants), 

. la tarification des differentes classes de service est 
problematique : une difference de prix est necessaire mais peut etre mal 
pergue par les utilisateurs si une difference en qualite n'est pas man.feste, 
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- I'absence de relation directe entre tarif et cout rend difficile 
la definition d'une tarification permettant ie necessaire retour sur 
investissement. 

5 L'Internet auto-gere evite bon nombre d'inconvenients parmi 

- ceux precedemment cites mais s'appuie sur un principe de tarification qui 
est lui-meme probiematique : 

la mise en oeuvre d'une tarification basee sur les marques 
ECN est cornplexe et sujet a contestation, 
10 - comment facturer un usager abonne au reseau de 

I'operateur A pour les marques de congestion provenant du reseau aval 
appartenant a un autre operateur B ? 

- Ie revenu de la tarification ECN n'assure pas le retour sur 
investissement d'un reseau bien dimensionne ; sachant qu'un autre 

15 principe de tarification doit assurer ce retour, la tarification ECN pourrait 
paraitre aux usagers comme une surcharge injustifiee. 

[.'architecture de type « flow-aware » exposee dans les 
publications citees ci-dessus possede encore les inconvenients suivants : 
20 - la differenciation explicite entre trafic temps reel et trafic de 

donnees necessite de controler le debit crete des flots temps reel, 

il est necessaire de fixer un debit crete maximal pour les flots 
temps reel et de le controler rigoureusement, alors qu'en I'absence de 
k congestion; i I serai t possible- d'admettre des flots a plus fort debit sans 
25 nuire a la performance, 

la performance reste vulnerable a la malveillance eventuelle 
de la part des utilisateurs, 

- les methodes proposees pour mesurer I'etat de congestion 
(estimation de la bande passante disponible avec une connexion TCP 

30 fantome ou a partir de I'observation du taux de perte) peuvent etre 
difficiles a mettre en oeuvre. 

Quant a Tarchitecture de type « flow-aware » de Caspian, 
signalons les inconvenients suivants : 
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- la prise en compte de parametres de qualite de service et de 
trafic par Hot necessite une mise en oeuvre complexe qui pourrait poser 
des problemes d'extensibilite, 

- la litterature disponible sur cette architecture ne precise pas 
les methodes employees pour faire respecter la qualite de service des 
flots ; or, ces methodes, et notamment la definition des principes de 
controle d'admission, sont determinates pour I'efficacite de ('architecture 
proposee, 

- les ordonnancements evoques (espacement en entree, WFQ 
par flot en sortie) necessitent de connaTtre des parametres specifiques par 
Hot (notamment, s'ils sont de type temps reel - GR, MR - ou de type 
donnees - AR) afin de respecter leurs exigences de qualite de service. 

- la question de la tarification n'est pas abordee. 

Expose de I'invention : 

L'invention a tout d'abord pour objet un dispositif ainsi qu'un 
procede de traitement de paquets des flots sur un lien de reseau, 
comportant des moyens, respectivement une etape, d'ordonnancement 
pour ordonner les paquets dans une Hie d'attente, selon un algorithme de 
partage equitable avec priorite. 

Un ordonnancement de type « partage equitable avec priorite- » 
permet de donner priorite aux paquets des flots dont le debit est inferieur 
a un seuil dynamique. Ce seuil correspond par exemple .au debit 
actuellement realise par les flots qui ont plusieurs paquets en attente 
sachant que ces derniers sont desservis selon un algorithme de type « 
partage equitable ». 

Un tel dispositif ou procede peut fonctionner, sans moyens de 
controle d'admission, notamment dans le cadre d'un reseau d'acces ou le 
risque de congestion est davantage maitrisable qu'en cceur de reseau. 

Selon I'invention, on peut aussi associer un controle d'admission 
par flot avec un ordonnancement du type « partage equitable » (« fair 
queueing » en anglais). 

L'invention a done egalement pour objet un dispositif et un 
procede de traitement de paquets des flots sur un lien de reseau, 
comportant : 
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des moyens, respectivement une etape, de controle 
d'admission pour controler ['admission desdits flots dans le dispositif, seion 
des criteres dits criteres d'admission, 

des moyens, respectivement une etape d'ordonnancement 
5 pour ordonner ies paquets dans une file d'attente, selon un algorithme de 
partage equitable avec priorite. 

Les moyens d'ordonnancement peuvent envoyer aux moyens de 
controle d'admission des donnees de conditions d'admissibilite. 

Ce dispositif et ce procede permettent d'assurer une qualite de 
10 service, sans explicitement distinguer entre flots temps reel et flots des 
donnees. 

Ainsi, on minimise le delai des paquets des flots temps reel, dont 
le debit reste inferieur a un seuil determine par les conditions d'admission. 
Si le controle d'admission n'est pas active, ce seuil est determine plutot 
15 par les conditions de trafic. 

Les conditions d'admissibilite sont determinees directement par 
des moyens d'ordonnancement qui mesurent le debit equitable realise par 
les flots de donnees ainsi que la charge representee par les paquets 
prioritaires. 

20 L'association du controle d'admission et I'ordonnancement de 

type partage equitable permet de realiser une certaine « protection 
croisee » : 

- on protege le debit des flots de donnees en assurant un partage 
equitable, 

25 - on protege le delai paquet des flots temps reel en leur assurant la 

priorite, 

- on evite la complexity de I'ordonnancement partage equitable en 
limitant par controle d'admission le nombre de flots a prendre en compte, 

- le controle d'admission est facilite par les mesures integrees aux 
30 moyens d'ordonnancement. 

En associant les techniques de controle d'admission (implicite) et 
I'ordonnancement de partage equitable, Tinvention permet d'assurer une 
qualite « adequate » sans declaration de caracteristiques de trafic, sans 
definition de classes de service, sans signalisation et sans reservation 
35 explicite de ressources. 



1 er depot 



Si le controle d'admission n'est pas active, on perd certains 
avantages de la protection croisee mais on preserve la differenciation 
implicite de qualite de service a condition que le lien ne soit pas en 
congestion. Les paquets des flots temps reel de faible debit ne subissent 
5 qu'une attente faible alors que les flots de donnees peuvent atteindre le 
debit assure par le partage equitable. Cette configuration peut suffire 
notamment dans le cas d'un lien du reseau d'acces ou le risque de 
congestion est moindre du fait du nombre relativement faible d'utilisateurs 
desservis. 

10 L'ordonnancement choisi rend I'architecture invulnerable a la 

non-cooperation eventuelle de la part des utilisateurs. L'architecture 
permet une tarification simple sur la base du volume de trafic emis ou 
. regu. On retient la simplicity des relations usager-operateur du reseau 
auto-gere sans les inconvenients lies a la tarification en fonction des 

15 marques ECN. Cette simplicite s'accompagne de la robustesse et de 
I'efficacite de I'architecture « flow-aware ». 

Les flots dont le debit en arrivee est tel qu'ils maintiennent au 
moins un paquet dans la file d'attente realisent en sortie 
approximativement le meme debit dit « debit equitable ». Selon 

20 ('invention, si les paquets d'un flot temps reel arrivent en rafale avec un 
debit momentanement superieur au debit equitable (a cause d'attentes 
dans les files amont, par exemple), le dispositif d'ordonnancement fera 
passer le premier paquet en priorite mais retardera les suivants en 
imposant un espacement compatible avec le debit equitable. Si le debit 

25 primitif du flot est inferieur a ce debit equitable, I'espacement « lisse » le 
flot en n'introduisant pas de delai supplemental par rapport au delai 
impose par la memoire de reception a la destination (qui doit emettre a 
I'utilisateur final les paquets a leur cadence initiale). Dans ce sens, le delai 
reste negligeable. Un flot temps reel dont le debit est superieur au debit 

30 equitable serait par contre altere et la source typiquement obligee a une 
reduction de debit pour eviter la perte de paquets. 

Les mecanismes mis en oeuvre garantissent done un delai et une 
perte de paquet negligeables pour les flots dont le debit crete, determine 
par des elements exterieurs au reseau en question, est inferieur a un 

35 certain seuil. Ce seuil est dynamique et correspond au debit equitable (au 
sens max-min) realise par l'ordonnancement choisi. Le controle 
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d'admission realise alors le double objectif de conservation du debit des 
flots de donnees et de conservation du signal des flots temps reel. 

Le controle d'admission rend extensible I'ordonnancement de 
partage equitable en limitant le nombre de flots a prendre en compte. Le 
5 partage equitable facilite la mesure de I'etat de congestion du lien 
desservi, mesure qui permet de determiner les conditions d'admission. 

; L'invention permet d'utiliser un dispositif et un procede 
d'ordonnancement de type partage equitable avec priorite pour distinguer 
de maniere implicite les flots temps reel et les flots de donnees, en 
10 assurant aux premiers un delai par paquet faible. 

L'association du controle implicite d'admission par flot avec 
I'ordonnancement de partage equitable avec priorite permet d' assurer la 
quaiite de service sans explicitement distinguer les flots temps reel et 
donnees. 

15 On peut utiliser un mecanisme de partage de charge pour 

realiser un acheminement adaptatif a partir de I'identifiant des flots. En 
effet, le controle d'admission refuse les flots qui arrivent lorsque le lien est 
en congestion en rejetant le premier paquet regu. Le trafic correspondant 
n'est pas perdu pour autant si I'utilisateur renouvelle sa tentative en 

20 reemettant le meme paquet jusqu'au succes. La probability de succes est 
plus grande si a chaque tentative le paquet est presente a un autre lien 
capable de Pacheminer vers sa destination. 

A cette fin le mecanisme de partage de charge employe par le 
routeur peut agir sur I'identificateur de flot, celui-ci comportant un champ 

25 rempli librement par I'utilisateur (par exemple, un numero de port en 
IPv4, le « flow label » en IPv6). La fonction de « hash » realisant le 
partage de charge inclut comme argument ce champs libre de sorte que 
I'utilisateur realise une forme de routage adaptatif en modifiant la valeur 
du champ en question a chaque renouvellement. 

30 L'invention permet de combiner la robustesse du reseau avec 

connaissance des flots avec la simplicity de ('Internet autogere. On retient 
du premier le controle implicite d'admission en evitant la necessite pour 
I'utilisateur de distinguer le trafic temps reel du trafic de donnees. Cette 
distinction est faite automatiquement par le reseau en exploitant leurs 

35 differentes caracteristiques de trafic. 
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Breve description des figures : 

- la figure 1 represente schematiquement des elements de 
I'architecture « flow-aware networking », 

5 - la figure 2 represente des elements d'une architecture selon 

1'invention, 

la figure 3 est un diagramme de region d'admissibilite, 
la figure 4 represente le principe d'une file d'attente PIFO, 

- les figures 5 et 6 represented un algorithme s'executant soit 
10 a I'arrivee d'un paquet soit a la fin d'une emission d'un paquet, 

- les figures 7 et 8 represented les operations qui assurent la 
mesure des indicateurs de congestion, charge prioritaire et debit 
equitable. 

15 

Description detaillee des modes de realisation de 
I'invention : 

Un premier mode de realisation est illustre en figure 2. 

20 

Sur cette figure, la reference 24 designe un module ou des 

moyens d'acheminement, qui effectuent le controle d'admission des 

paquets 20 des flots entrants. 

La definition d'un flot est par exemple celle de I'architecture 
25 flow-aware exposee dans I'article de Bonald et al. " IP traffic and QoS 

control: the need for a flow-aware architecture", World Telecom 

Conference, Paris, 2002. 

Les paquets 20 presentes a ce module sont par exemple 

determines par des fonctions d'acheminement classiques qui peuvent 
30 inclure un partage de charge obtenu en appiiquant une fonction « hash » 

a un sous-ensemble des champs de I'identificateur de flot. Une forme de 

routage adaptatif est realisee en incluant dans ce sous-ensemble un 

champ de I'entete rempli librement par I'utilisateur (numero de port du 

protocole de transport, « flow label » de IPv6). 
35 Le module 24 consulte et met a jour une liste 30 de flots dits 

« proteges » : il s'agit, en fait, des flots admis (par les moyens 24) et 
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actifs (c'est-a-dire qu'un nouveau paquet du flot a ete identifie a I'interieur 
d'une certain intervalle de temps). 

La reference 28 designe un module ou des moyens 
d'ordonnancement, qui vont permettre de gerer la file d'attente des 
5 paquets selon un algorithme ou un precede de partage equitable avec 
priorite. 

Selon cet algorithme, ou ce precede, sont prioritaires les paquets 
des flots dont le debit ne depasse pas le seuil correspondant au debit 
equitable actuel. Cette condition se manifeste par les valeurs de certains 
10 parametres de I'algorithme de partage equitable employe, comme indique 
plus loin dans le cadre d'une realisation particuliere. Au contraire, les 
paquets des flots dont le debit d'arrivee depasse le debit equitable sont 
classes comme « non-prioritaires ». 

Ceci permet d'ailleurs de reguler le debit crete des flots temps 
15 reel. En effet, les flots entrants 20 dont le debit est trop eleve seront 
identifies par le module d'ordonnancement 28 et retrogrades ou classes en 
tant que « non-prioritaires ». 

Ce mecanisme remplace done et permet d'eliminer le module 4 
de police du debit crete des flots temps reel de la figure 1. 
20 Par ailleurs, le module ou les moyens 28 vont fournir des 

donnees ou des parametres 36 de conditions d'admissibilite au module 24 
d'acheminement. 

Enfin, la reference 32 designe le depart des paquets tandis que 
les references 34 et 38 designent le rejet des paquets respectivement par 
25 le module d'ordonnancement et par le module de controle d'admission. 

Rappelons que dans un mode d'utilisation de ('invention, le 
module de controle d'admission peut etre absent de sorte que les flots 20 
se presente directement au module 28. 

Ce mecanisme n'a pas besoin d'identifier a priori les paquets ou 
30 les flots comme etant de type temps reel ou elastique. 

Typiquement, Tarchitecture de la figure 2 sera implementee ou 
realisee dans un routeur ou dans un processeur ou un microprocesseur 
pour un routeur, programme pour realiser les fonctions souhaitees. 

Un exemple de realisation du module 24 de decision 
35 d'acheminement va maintenant etre decrit un peu plus precisement. 
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Dans un reseau IP classique, les flots sont achemines sur un 
chemin unique, determine par I'adresse IP de destination, 
independamment de son etat de congestion. Dans la presente 
architecture, un module de decision d'acheminement 24 decide, sur la 
5 base d'informations contenues dans une ou plusieurs listes 30 de flots 
proteges (LFP), si les paquets d'un flot donne doivent etre achemine ou 
non. 

Une liste de flots proteges 30 est une liste d'identificateurs de 
flots indiquant pour chacun I'heure d'arrivee du dernier paquet. Chaque 
10 liste est associee a une partition de I'espace des identificateurs. Cette 
partition permet de limiter la capacite de chaque liste et done de garantir 
I'extensibilite. 

Un flot est efface de la liste 30 lorsque le temps ecoule depuis le 
dernier paquet recu pour le flot depasse un seuil ou un intervalle de 

15 temporisation. La longueur de cet intervalle est un parametre du systeme; 
par exemple de I'ordre de quelques secondes. De preference, on 
dimensionne la table pour limiter la probability de saturation, e'est-a-dire 
un etat ou un flot devrait etre admis dans la liste, alors que celle-ci est 
pleine. La consequence d'une telle saturation serait seulement qu'un flot 

20 tarderait a acquerir le statut de flot protege. Ses paquets seraient 
neanmoins achemines correctement si I'etat de congestion le permet. La 
probabilite de saturation peut etre rendue suffisamment faible par un 
dimensionnement adequat. 

Les decisions d'acheminement sont prises a . I'arrivee de tout 

25 paquet. Le module 24 determine conjointement, a partir des informations 
de I'entete du paquet, I'interface de sortie et la liste appropriee. Si le 
paquet appartient a un flot protege, il est achemine directement. L'heure 
d'arrivee du dernier paquet est mise a jour dans la liste. Si le flot n'est pas 
deja protege, il faut proceder a une prise de decision d'acheminement. 

30 Le paquet sera rejete si des conditions d'admission ne sont pas 

satisfaites. La nature de ces conditions est expliquee plus loin. Les 
conditions appliquees peuvent dependre d'attributs particuliers du paquet 
dont la valeur du champ « classe de trafic » en Ipv6, ou le champ ToS en 
Ipv4 ou des adresses IP source et destination. 

35 Le controle d'admission permet d'assurer la transparence des 

flots admis : conservation du signal pour les flots temps reel, conservation 
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du debit pour les flots de donnees. En fait, cette transparence n'est offerte 
qu'aux fiots dont le debit crete (determine par les limitations externes) 
reste inferieur a un certain seuil. Le seuil de debit admissible est plus 
faible pour les flots temps reel que pour les flots de donnees car les 

5 garanties de transparence respectives (c'est-a-dire, conservation de debit 
et conservation de signal) impliquent des echelles de temps differentes 
dans les deux cas. Pour un flot temps reel, on cherche a s'assurer que le 
debit disponible soit plus grand que son debit crete sur une petite echelle 
de temps, compatible avec un delai « negligeable » des paquets (quelques 

10 millisecondes). Pour les flots de donnees, on cherche a realiser 
approximativement un certain debit moyen sur une duree relativement 
grande (de I'ordre de quelques secondes). 

Les deux debits cretes en question resultent du choix des 

15 criteres d'admission. Autrement dit, pour assurer la transparence des flots 
d'un certain debit, on definit une condition d'admission appropriee basee 
sur les mesures de congestion « debit equitable » et « charge 
prioritaire ». Pour le cas ou les flots sont tous elastiques, le choix d'un 
seuil approprie pour le debit equitable est par exemple decrit par Ben 

20 Fredj et al. (Measurement based admission Control for Elastic Traffic, 
Teletraffic Engineering in the Internet Era, ITC 17, Elsevier, 2001). Soit 
threshold^! (Tl) le seuil en question. Si tous les flots sont de type temps 
reel a debit crete borne, un seuil d'admission sur la charge prioritaire peut 
etre deduit de I'approche de Gibbens et al « A decision theoretic approach 

25 to Call Admission in ATM Networks », IEEE J. on Selected Areas in 
Communications, Vol. 13, No. 6, p. 1101-1114, 1995. Soit threshold^ (T2) 
ce deuxieme seuil. 

A titre d'exemple, la figure 3 montre une region d'admissibiiite 
definie par ces deux seuils. On refuse un nouveau flot si le debit equitable 

30 est inferieur a Tl (zone I sur le graphique) ou si la charge prioritaire est 
superieure a T2 et si le debit equitable est inferieur a T2 (zone II). En 
effet, si la charge prioritaire depasse le seui! T2, mais si le debit equitable 
lui est superieur, c'est une indication que les paquets comptes comme 
■ prioritaires ne proviennent pas exclusivement de flots temps reel a debit 

35 crete borne. Par experimentation, on peut affiner la definition de cette 
region d'admissibilite. 
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On definit une fonction logique Admit (debit equitable, charge 
prioritaire) telle que si Admit vaut 1, il est possible d'accepter un nouveau 
Hot et si Admit vaut 0, les nouveaux flots doivent etre refuses. Selon un 
exemple simple de politique d'admission, tous les flots sont acceptes ou 

5 refuses dans les memes conditions. En effet, on ne peut deviner la nature 
d'un flot a priori. On fait done une hypothese « pire cas » et on considere 
que le nouveau flot pourrait etre le plus exigeant et le plus derangeant 
possible. Cette politique assure que tous les flots sont traites de maniere 
equitable vis-a-vis du blocage. 

10 Si, d'apres les conditions d'admission, le paquet ne doit pas etre 

refuse, il est achemine via le lien correspondent. L'identite du flot est alors 
candidate pour inclusion dans la liste 30. Plusieurs criteres 
supplementaires pourraient etre definis pour finalement autoriser cette 
inclusion. En particulier la decision pourrait etre probabiliste : avec 

15 probabilite p le flot est rajoute, avec probability 1-p le paquet est 
achemine mais le flot reste non protege. Cette probabilite p peut dependre 
des attributs du paquet dont la valeur du champ « classe de trafic », du 
champ ToS ou des adresses IP. 

Si p est faible (0.1, par exemple), la plupart des flots de petite 

20 taille ne seront pas pris en compte alors que les grands flots seront 
proteges des remission des premieres dizaines de paquets. Un 
inconvenient de choisir p < 1 est le rejet possible d'un flot en cours : les 
paquets initiaux sont transmis mais une decision de controle d'admission 
vient interdire le flot avant qu'il ne passe a I'etat de flot protege. . 

25 En ce qui concerne ies conditions d'admission mentionnees ci- 

dessus, elles vont dependre de mesures de congestion effectuees au sein 
du dispositif ou des moyens 28 d'ordonnancement. On peut par exemple 
mesurer deux indicateurs, le debit equitable et la charge prioritaire : 

le debit equitable est une mesure du debit que realiserait un 

30 flot de donnees qui aurait toujours des paquets a emettre, 

la charge prioritaire est la somme de la longueur des paquets 
prioritaires, transmis dans un certain intervalle, divisee par la duree de cet 
intervalle. 

Pour estimer le debit equitable, on peut inclure dans I'algorithme 
35 d'ordonnancement un flot de paquets fictifs et on mesure le debit 
qu'aurait recu ce flot en supposant qu'il a toujours des paquets a emettre. 
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Bien entendu, les paquets fictifs ne sont pas reellement emis. On distingue 
deux cas : 

en presence de flots avec plusieurs paquets en attente, le 
flot fictif insere ses paquets de maniere cyclique entre leurs emissions en 
5 laissant passer les paquets prioritaires, 

- lorsque la file d'attente est vide (aucun paquet reel en 
attente), le flot fictif est theoriquement asservi au debit du lien . Le calcul 
du debit equitable en fin de periode de mesure tient compte de ces 
periodes d'inactivite. 
10 En effectuant des mesures periodiques, on obtient un comptage 

en continu de I'etat de charge du lien controle. La periode des mesures 
serait typiquement differente pour les deux valeurs de debit equitable (par 
exemple, de I'ordre de la centaine de millisecondes) et de charge 
prioritaire (par exemple, de I'ordre de la dizaine de millisecondes). 
15 Les estimations utilisees par !e controle d'admission pourront 

etre, par exemple, des moyennes exponentiellement lissees des mesures 
par cycle (c'est-a-dire, estimateur <-ax estimateur + ( 1 - a)x nouvelle 
mesure, pour 0 < a < 1). 

Un exemple de realisation du module 28 d'ordonnancement va 
20 maintenant etre decrit plus precisement, 

De preference est mis en oeuvre un ordonnancement de type 
partage equitable (« fair queuing » en terminologie anglo-saxonne). 

Un tel ordonnancement, dit SFQ, est par exemple decrit dans 
('article de - P. -Goyal et al. "Start-time Fair Queueing: A. scheduling 
25 algorithm for integrated services packet switching network", IEEE/ACM 
Trans. Networking, Vol 5, No 5, pp 690-704, 1997. 

Ce type d'ordonnancement permet de partager de maniere 
equitable la bande passante d'un lien entre les flots en cours en 
s'affranchissant du comportement cooperatif des utilisateurs. Associe au 
30 controle d'admission, il permet en plus d'offrir une garantie de debit aux 
flots admis. 

Les problemes d'extensibilite associes au « fair queuing » par 
flot sont evites, dans la presente architecture, en ne maintenant I'etat d'un 
flot que pendant le temps ou il est actif et en observant que le nombre de 
35 tels flots est necessairement limite par le controle d'admission. 
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Priorite est donnee aux paquets arrivant lorsque le flot n'est pas 
« actif » dans ie sens qu'il n'est pas inventorie dans une liste de flots. Ceci 
veut dire qu'il n'a pas deja des paquets dans la file d'attente et n'en a pas 
eu depuis un certain intervalle de temps (determine par les parametres 

5 courants de I'algorithme de partage equitable SFQ). En principe, un flot 
dont le debit crete ne depasse pas le debit equitable ne sera pas actif lors 
de I'arrivee des paquets de ce flot. 

Cette adaptation, couplee avec le controle d'admission, permet 
done d'assurer une alteration negligeable aux flots temps reel dont le 

10 debit ne depasse pas un certain seuil. 

Puisqu'on ne distingue pas, dans cette architecture, les flots 
temps reel et les flots de donnees, le dispositif d'ordonnancement donnera 
la priorite egalement a certains paquets des flots de donnees (tous les 
paquets d'un flot dont le debit reste inferieur au debit equitable, par 

15 exemple). 

Cette ambiguite ne pose pas de probleme tant que le controle 
d'admission assure un delai negligeable pour les paquets prioritaires. 

Pour illustrer le fonctionnement du dispositif d'ordonnancement, 
Texemple d'un routeur va etre donne, ou la file d'attente se realise 
20 uniquement en sortie (en anglais, routeur avec « output queueing »). 

Est mis en oeuvre un systeme de file d'attente de type « PIFO » 
(abreviation de I'expression anglaise « Push in, first out »), qui admet un 
paquet a n'importe quelle position, determinee par ia valeur d'une 
estampille. La file se vide toujours par sa tete : le paquet qui est 
25 positionne en tete de file est emis. 

Selon cet exemple, le dispositif met en oeuvre les donnees 
suivantes ou les elements suivants : 

une file « push in, first out » (PIFO) ou les paquets sont 
stockes en ordre croissant d'une estampille; les elements du PIFO sont 
30 des ensembles {packet, time_stamp} ou packet designe les informations 
afferentes au paquet (identificateur de flot, taille, adresse de stockage) et 
time_stamp est I'estampille (determinee selon I'algorithme SFQ decrit plus 
loin), 

un pointeur P identifiant le dernier des paquets prioritaires a 
35 la tete de la PIFO; si la file ne contient aucun paquet prioritaire, P= zero, 
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une liste de flots flowjist contenant i'identificateur des flots 
actifs ainsi qu'une estampille de flot flow_time_stamp correspondant a la 
valeur de time_stamp du dernier paquet augmentee de sa longueur (il 
s'agit du « finish tag » du paquet en SFQ), 
5 - un compteur de temps virtuel virtual_time permettant le 

calcul des estampilles. 

Dans I'exemple de I'algorithme SFQ, deja indique ci-dessus, le 
temps virtuel est egal a I'estampille (« start tag ») du dernier paquet a 
10 avoir commence son emission. 

Les estimateurs de congestion utilisent les donnees suivantes: 

- le temps actuel {locaLtime) selon I'horloge locale, ■ 

- le nombre d'octets de paquets prioritaires transmis pendant 
15 I'intervalle de mesure courant, priority_bytes. 

- une variable logique indiquant si la file d'attente est vide, 
silence_fiag ( 

la duree cumulee des intervalles de silence, silence_time, 
Pheure de debut de I'intervalle de silence en cours, 

20 silence_start. 

La figure 4 represente schematiquement une file d'attente 50 de 
type PIFO. Un paquet 52 y est insere en fonction de son estampille. Un 

25 paquet prioritaire 56 est a inserer dans les paquets de tete, le paquet 54 
etant le prochain paquet a devoir etre emis. Le paquet 56 va etre insere 
comme dernier des paquets prioritaires : c'est sur lui que le pointeur P va 
pointer, apres son insertion dans la file. Notons que tous les paquets 
prioritaire 'heritent de la meme estampille, egale a la valeur courante de 

30 virtuaLtirne. 

Pour estimer la charge prioritaire, il convient de mettre a jour, a 
chaque insertion dans la file PIFO d'un paquet prioritaire, un compteur 
d'octets priority_bytes. Ce compteur est alors increments de la valeur L 
35 representant la taille en octets du paquet. En echantillonnant ce compteur 
a intervalles reguliers, on deduit une estimation de la charge prioritaire 
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comme la difference dans la valeur priority_bytes au debut et a la fin de 
I'intervalle de mesure divise par sa duree. Soit PB(T) la valeur de 
priority_bytes a I'instant T, (Tl, T2) un intervalle de mesure (en 
secondes), C le debit du lien (en bits/seconde). Mors un estimateur de 
5 charge prioritaire pour I'intervalle est : 

charge prioritaire = (PB(T2) - PB(T1))*8/(T2 - Tl) / C. 

Pour estimer le debit equitable, plusieurs approches sont 
possibles sachant que, d'apres Ben Fredj et al. dans ['article deja cite, 

10 cette mesure ne doit pas etre evaluee avec une tres grande precision. Une 
methode possible serait de compter le nombre de flots actifs (le nombre 
de flots dans la liste flowjist) et de prendre comme mesure de debit 
equitable, le debit du lien divise par ce nombre. Dans les aigorithmes 
decrits plus loin on utilise une autre approche basee sur la notion precitee 

15 de flot fictif. 

On suppose que le flot fictif emet des paquets de longueur 1 
octet qui s'inserent entre les paquets reels dans un ordre dicte par 
I'algorithme SFQ. Dans une periode ou la file est toujours occupee, le 
nombre d'octets qu'aurait pu emettre le flot fictif se deduit de revolution 

20 du compteur de temps virtuel virtual_time. Lorsque la file est vide, le flot 
fictif aurait pu emettre au debit du lien. En conjuguant la succession de 
periodes d'occupation et de silence, on deduit I'estimateur suivant. Soit 
VT(T) la valeur de virtual_time a I'instant T, (Tl, T2) un intervalle de 
mesure et S la duree totale de silence pendant cet intervalle. Mors, 

25 I'estimateur choisi est : 

debit equitable = max( S*C /(T2 - Tl), (VT(T2) - VT(T1)) *8 / (T2 - Tl)) 
Le premier terme prevaut typiquement lorsque la charge du lien est faible 
car le flot fictif aurait utilise toute la capacite du lien restant disponible. Le 
deuxieme terme prevaut en periode d'occupation et mesure 

30 approximativement le debit realise par un flot reel qui a toujours au moins 
un paquet dans la file. 

Les operations de I'algorithme s'executent soit a I'arrivee d'un 
paquet, soit a la fin d'une emission de paquet comme illustre en figures 5 
35 et 6. Dans ces figures, les operations encadrees par des lignes en 
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pointilles s'afferent aux mesures de congestion et sont commentees plus 
loin. 

Sur la figure 5, le debut de I'algorithme correspond a I'etape 
d'arrivee d'un paquet (etape 100). 
5 II est d'abord determine (etape 102) si la file PIFO est 

congestionnee, ou pas. 

Si elle Test, il est procede au choix du paquet a eventuellement 
rejeter (etape 104). 

Le paquet peut etre rejete (etapes 106 et 108) ou pas, auquel 
10 cas (un paquet d'un autre flot est alors rejete), il est procede au test de 
I'etape 110, de meme que si la reponse a I'etape 102 est negative. 

L'etape 110 est un test sur 1'appartenance de I'identificateur du 
paquet a la liste des flots. 

Si I'identificateur de flot du paquet n'appartient pas a la liste des 
15 flots, c'est que le flot auquel appartient ce paquet n'est pas actif. Ce type 
de paquet obtient une priorite, dans le cas ou la liste des flots {flow list) 
n'est pas saturee. Si cette derniere Test (etape 120), il est procede au 
rejet du paquet, (etape 108). Sinon, la liste flowjist, est mise a jour en 
rajoutant I'identificateur du nouveau flot avec une estampiile de flot 
20 flow_ time__stamp egale a virtualjime augmente de la longueur du paquet 
L (etape 124). Le paquet est insere dans la file PIFO a la position indiquee 
par le pointeur Pet la valeur de ce dernier est mise a jour (etape 124). 

Si le flot appartient deja a la liste des flots actifs (reponse 
positive a I'etape 110), le paquet est insere a la file PIFO avec une 
25 estampiile egale a la valeur courante de flowJime_stamp (etape 122). 
Cette valeur dans flowjist est alors incrementee par la longueur L du 
paquet. 

L'algorithme est alors termine (etape 134). L'arrivee d'un 
nouveau paquet redeclenchera le meme algorithme. La fin d'admission 
30 d'un paquet declenchera l'algorithme suivant (figure 6). 

Les operations encadrees en pointilles permettent de mesurer en 
continu les parametres de congestion debit equitable et charge prioritaire. 
Si la file PIFO est vide (etape 210), on observe la fin d f une periode de 
silence. Le compteur de duree de silence silence_time est mis a jour et 
35 I'indicateur logique silence_flag est mis a la valeur FAUX (etape 212). Par 
ailleurs, lorsque un nouveau flot est ajoute a la liste flowjist, la valeur de 
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priority_bytes est incrementee par la longueur du paquet en question 
(etape 204). 

L'algorithrne de la figure 6 est decienche par un autre 
5 evenement, a savoir la fin d'emission d'un paquet (etape 150). 

Dans une premiere etape (etape 154), il est determine si la file PIFO est 
vide ou pas. 

Si oui, tous les flots encore actifs sont effaces de la liste flowjist 
(etape 156). Le pointeur ^est reinitialise. 
10 Si non, on procede a remission du prochain paquet en notant la 

valeur. de son estampille next_time_stamp (etape 160). Si 
next_time__stamp n'est pas superieur a virtuaLtime (ces variables sont 
• dont de valeurs egales), l'algorithrne est termine. Dans le cas contraire, il 
y a lieu de changer virtuaLtime et de proceder a Teffacement de flowjist 
15 des flots devenus inactifs, leur flow_time_stamp etant inferieur a virtual 
time (etape 164). L'algorithrne est alors termine. 

Les operations liees aux mesures de congestion sont encadrees 
en pointilles. Lorsque la file se vide, I'indicateur silence_flag est mis a la 
valeur VRAI I'epoque du debut de la periode de silence est enregistree 
20 (etape 220). 

L'arrivee d'un nouveau paquet declenchera Talgorithme 
precedent (figure 5), la fin d'emission d'un paquet declenchera de 
nouveau l'algorithrne de la figure 6. 

Les figures 7 et 8 indiquent les operations effectuees lors de 
25 Pechantillonnage des compteurs de congestion. 

Les operations de la figure 7 sont executees toutes les 
timeJntervaLCP secondes (selon I'horioge local). On calcule la charge 
prioritaire (etape 232) et on stocke la valeur courante du compteur 
priority_bytes pour la prochaine execution comme la variable 
30 priority_bytes_oid 

Les operations de la figure 8 sont executees toutes les 
timeJntervaLDE secondes (selon I'horioge local). Les calculs different 
selon que le lien est silent (file d'attente vide) ou non. Si oui, le silence est 
interrompu pour les besoins des calculs (etape 248). Dans tous les cas on 
35 obtient une estimation rate_l du debit equitable correspondant au debit 
disponible pendant I'intervalle de mesure (etape 246 ou 248). On calcule 
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ensuite le deuxieme estimateur de debit rate_2 selon la formule de I'etape 
250. Le debit equitable est le plus grand 'des deux estimateurs rate_l et 
rate_2 (etapes 254, 256 et 258). Enfin, les valeurs actuels de silence^time 
et virtuaLtime sont memorisees pour le prochain intervalle (etape 252). 

Une autre application calcule des moyennes glissantes a partir 
des valeurs exportees a la fin de chaque periode de mesure. Le choix des 
poids de lissage et de la longueur des intervalles de mesures est a 
optimiser en fonction des parametres du systeme et du trafic. Cette 
application fournit les estimateurs debit equitable et charge prioritaire et 
deduit la valeur de la fonction Admit deja introduce ci-dessus. 

Le choix du paquet a rejeter a I'etape 104 de la figure 5 se faiten 
assurant t'equite du partage de debit entre les flots actifs. Ce!le-ci est 
assuree en choisissant pour rejet un paquet du flot dont le nombre total 
d'octets en attente est le plus grand. Des conditions de rejet ainsi qu'un 
mecanisme du choix du paquet a rejeter sont par exemple divulguees 
dans I'article de B.Suter et al. « Buffer Management schemes for 
supporting TCP in Gigabit Routers with Per-Flow Queuing », IEEE 1 in 
Selected Areas in Communications, August 1999. Notons enfin, que le 
rejet de paquet pourrait etre remplace dans certains cas par un simple 
marquage avec I'utilisation du bit ECN (« explicit congestion notification ») 
de I'entete IP. 

Le procede selon invention est extensible : il fonctionne quelles 
que soient les conditions de charge, par exemple sur un lien a IMbit/s ou 
a lOMbit/s ou a lGbit/s ou plus. . .. • , 

La complexite du mecanisme d'ordonnancement et notamment 
du SFQ, est lineaire dans le nombre de flots actifs. L'extensibilite est 
assuree par le fait que ce nombre est limite par le controle d'admission et 
reste relativement faible, independamment du debit du lien C. 

Pour estimer ce nombre, supposons d'abord que le controle 
d'admission fonctionne parfaitement et assure que le debit equitable ne 
descende jamais en dessous d'une valeur able 9. Le nombre de flots dont 
le debit pourrait depasser 6 (car non limite par d'autres elements sur leur 
chemin) est forcernent inferieur ou egal a C/9 : On choisit 6 tel que la 
probability d'avoir plus que C/9 flots actifs soit tres faible tant que la 
charge ne depasse une certaine limite. Pour une limite de charge de 90%, 
d'apres I'analyse de Ben Fredj et al. (« Statistical Bandwidth Sharing: a 
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study of congestion at flow levels » Proc. of ACM SIGCOMM 2001), la 
probability que le nombre de flots depasse 100 est plus faible que 
1/10000. On peut done fixer 0 = C/100 de sorte que le nombre de flots 
actifs est toujours inferieur a 100, et la probabilite de blocage est 

5 inferieure a 10' 4 si la charge ne depasse pas 90%. 

Un grand nombre d'autres flots de debit inferieur a 0 peuvent 
etre en cours. Cependant, a tout instant, seulement un petit nombre 
parmi ces flots auront un paquet dans la file d'attente. Supposons pour 
simplifier que les paquets de tous les flots soient de meme longueur. Ces 

10 flots n'ont jamais qu'un seul paquet dans la file d'attente (puisque leur 
debit est inferieur au debit equitable). Si les flots sont independants, le 
nombre de paquets dans la file prioritaire se comporte alors comme une 
file d'attente M/D/l. De meme, le nombre de flots actifs (qui sorit 
inventories dans la liste des flots de Palgorithme partage equitable) est 

15 egal au nombre de clients participant a une periode d'occupation de la 
meme file d'attente. Ce dernier est inferieur a 100 avec une grande 
probabilite tant que la charge ne depasse pas 90%. 

L'impact de la taille variable des paquets et de la gigue acquise 
dans le reseau en amont ne changent pas le fait que le nombre de flots a 

20 prendre en compte dans des conditions normales de charge reste inferieur 
a quelques centaines (200 si on somme les limites ci-dessus). En cas de 
surcharge, le controle d'admission a justement pour role de limiter le 
nombre de flots en cours. Le controle du debit equitable limite 
naturellement le nombre de flots actifs. Le controle de la charge .prioritaire 

25 assure que la charge locale due aux flots de debit plus faible que le debit 
equitable reste en dessous de la limite fixee (90%, par exemple) avec une 
grande probabilite. 

La valeur optimale du nombre maximal de flots, en tenant 
compte de I'imprecision des algorithmes de controle d'admission, peut etre 

30 determinee en experimental les algorithmes decrits ci-dessus. 

Si le dispositif est employe sans controle d'admission, le nombre 
de flots a prendre en compte n'est pas limite. Ce fait pourrait ne pas etre 
genant dans le cadre d'un reseau d'acces ou le nombre d'utilisateurs 
desservi est lui-meme limite. 

35 Une discrimination pourrait etre souhaitable pour distinguer des 

classes de service au niveau du controle d'admission. II est en effet 



1er depot 

26 



possible de refuser certaines classes de flots a un certain niveau de 
congestion afin de preserver de la capacite pour d'autres flots d'une classe 
de service plus prioritaire. La priorite pourrait par exemple dependre de la 
valeur de differents champs de I'entete du paquet, dont la classe de trafic 
5 de Ipv6 ou le champs ToS de Ipv4 ou les adresses IP. 

On suppose done qu'il existe un ensemble de fonctions logiques 
Admit-! (debit equitable, charge prioritaire), i = !,..., m, pour m classes de 
service. La classe i est prioritaire par rapport a la classe j si i < j. Les 
fonctions sont telles que, pour les memes arguments, Admit_l > Admit_2 

10 >...> Admit_m. La politique d'admission est alors de rejeter les flots de 
classe d'index i si AdmitJ vaut 0 et de les admettre si Admitjvaut 1. 

Admit_l est choisie, comme la fonction Admit dans la politique 
simple sans classes, pour preserver la transparence des flots de debit 
crete inferieur aux debits cibles respectifs. Les autres fonctions, Adm/t_l 

15 pour i=2,...,m, permettent de privilegier i'accessibilite des classes 
prioritaires. 

Les limitations de debit crete ne sont pas « dures », en ce sens 
que les usagers peuvent les depasser sans probleme si les conditions de 
trafic le permettent. II s'agit d'une hypothese permettant le 

20 dimensionnement et I'etablissement des conditions precises d'admission. 
Les garanties affichees par I'operateur permettent aux usagers d'utiliser 
un codage non adaptatif pour les services temps reel tant que son debit 
crete est inferieur a la limite fixee. Le debit des transferts de donnees 
n'est restraint par le reseau que si les limites externes (reseau d'acces, 

25 capacite du serveur, ) sont superieures au debit crete cible. 

L'architecture selon I'invention n'est pas plus vulnerable aux 
comportements irrationnels ou mal intentionnes de la part des utilisateurs 
que les architectures connues de I'etat de la technique. Cependant, pour 
une performance optimale, une interpretation appropriee, par les 

30 applications, des signaux implicites constitues par la perte de paquets, est 
preferable. 

La perte des premiers paquets d 7 un nouveau Hot devrait etre 
interpretee comme le rejet de ce dernier. L'appiication sous-jacente 
pourrait continuer a emettre des paquets jusqu'a I'acceptation de Tun 
35 d'eux et Tinscription du flot dans la liste de flots proteges . Ces re- 
emissions ne sont pas plus nuisibles que le renouvellement de paquets 
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perdus par TCP. La possibility de routage adaptatif evoquee ci-dessus, 
permet une reaction plus intelligente. Si les premiers paquets sont perdus, 
le changement de I'identificateur du flot dans les paquets suivants permet 
de tester un autre chemin. 

5 Les applications temps reel peuvent emettre des paquets de test 

pour evaluer la disponibilite d'un chemin. L'acquittement d'un paquet de 
test est une bonne indication que le flot est accepte et inscrit a la liste de 
flots proteges. II n'y a pas besoin d'autres mecanismes specifiques au 
traitement des paquets de test. 

]0 Pour la plupart des communications, deux flots sont etablis, un 

dans chaque direction. Les utilisateurs pourraient avoir avantage a 
adopter la convention selon laquelle la partie libre de I'identificateur (ie flot 
label en Ipv6 ou les numeros de port en Ipv4) est la meme dans les deux 
sens. Ceci permettrait aux utilisateurs de reconnaitre les acquittements 

15 d'un flot particulier, notamment dans le cas d'un routage par inondation^:* : 
I'utilisateur envoie plusieurs paquets avec des identificateurs differents 
permettant de tester plusieurs chemins ; la communication se poursuit sur 
le flot qui est acquitte en premier. 

L'architecture n'introduit pas de nouvelles opportunites pour une 

20 attaque de type « DoS » (« denial of service »). Deux types de 
comportement peuvent etre envisages : 

un utilisateur change I'identificateur de flot avec chaque 
paquet : ceci pourrait rapidement saturer une liste de flots proteges ; la 
consequence serait la non-protection de certains flots mais ceux-ci n'en 

25 souffriraient qu'en cas de congestion simultanee du lien sous attaque ; 
inscription d'un flot sur la liste 30, avec seulement une faible probability 
p, reduit rim pact d'une telle attaque. 

un utilisateur preserve le meme identificateur pour plusieurs 
flots : les flots successifs ne seront pas soumis au controle d'admission 

30 tant que I'intervalle entre deux paquets reste inferieur a la temporisation ; 
les flots emis en parallele ne pourront realiser un debit global plus fort que 
la valeur courante du debit equitable ; la gene occasionnee aux autres 
utilisateurs est minime dans les deux cas. 
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Enfin, il est bien entendu possible pour un utilisateur d'etablir 
plusieurs flots pour le transport d'une meme application. II pourrait alors 
obtenir un debit plus fort, a condition que son debit crete le permette. 

Pour realiser I'equilibrage de charge sur des chemins a cout egal, 
la plupart des routeurs actuels appliquent une fonction de hash aux 
adresses IP de source et/ou de destination afin de choisir interface de 
sortie pour un paquet donne. Tous les paquets d'un meme flot suivent 
ainsi le meme chemin. On peut etendre I'argument de la fonction hash 
pour inclure egalement la partie libre de I'identificateur de flot (c'est-a- 
dire, le flow label en IPv6 ou les numeros de port en IPv4). Ainsi, le choix 
de route depend d'une valeur precisee par I'utilisateur. En cas d'echec sur 
une route, I'utilisateur est libre de changer I'identificateur et de reessayer. 
Au bout d'une ou de plusieurs tentatives, il pourrait trouver une route 
avec suffisamment de capacite. II pourrait meme initier plusieurs flots 
simultanement et ne continuer la communication que sur I'un d'eux - celui 
pour lequel on regoit en premier un acquittement, par exemple. 

Les elements de reseau mettant en oeuvre ('architecture seion 
I'invention pourront identifier les flots, par exemple par une fonction (de 
type « hash ») des attributs d'adresse. De preference, le choix de cette 
fonction permet un compromis entre la complexite de mise en oeuvre et la 
probabilite de confusion entre deux flots pour lesquels la fonction renvoie 
la meme valeur. Les effets d'une telle confusion sont limites : evitement 
eventuel d'un blocage par le controle d'admission, reduction du debit 
attribue aux flots par le fair queuing. 

Selon I'invention, un mecanisme de partage de charge est utilise 
pour realiser un acheminement adaptatif a partir de I'identifiant des flots. 
En effet, le controle d'admission refuse les flots qui arrivent lorsque le lien 
est en congestion en rejetant le premier paquet recu. Le trafic 
correspondant n'est pas perdu pour autant si I'utilisateur renouvelle sa 
tentative en reemettant le meme paquet jusqu'au succes. La probabilite 
de succes est plus grande si, a chaque tentative, le paquet est presence a 
un autre lien capable de I'acheminer vers sa destination. Cela est 
realisable si le mecanisme de partage de charge employe par le routeur 
agit sur I'identificateur de flot et si celui-ci comporte un champ rempli 
librement par I'utilisateur (par exemple, un numero de port en IPv4, le 
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« flow label » en IPv6). La fonction de « hash » realisant le partage de 
charge inclut comme argument ce champ libre de sorte que I'utilisateur 
realise une forme de routage adaptatif en modifiant la valeur du champ en 
question a chaque renouvellement. 
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Revendications 



1. Dispositif de traitement de paquets (20) des flots sur un 
lien de reseau, comportant des moyens d'ordonnancement (28) pour 
ordonner les paquets dans une file d'attente, selon un algorithme de 
partage equitable avec priorite. 

2. Dispositif selon la revendication 1, comportant en outre 
des moyens (24) de controle d'admission pour controler ('admission 
desdits paquets dans le dispositif, selon des criteres dits criteres 
d'admission. 

3. Dispositif selon la revendication 2, les moyens 
d'ordonnancement (28) envoyant aux moyens (24) de controle 
d'admission des donnees (36) de conditions d'admissibilite. 

4. Dispositif selon I'une des revendications 2 ou 3 les 
moyens de controle d'admission comportant des moyens pour 
interroger, pour chaque paquet entrant, une liste (30) de flots dits 
proteges. 

5. Dispositif selon la revendication 4, comportant egalement 
des moyens pour effacer de la liste (30) de flots proteges les flots pour 
lesquels le temps ecoule depuis le dernier paquet recu depasse une 
valeur seuil. 

6. Dispositif selon I'une des revendications 2 a 5, les moyens 
de controle d'admission comportant des moyens pour determiner 
lorsqu' un paquet appartient a un flot qui n'est pas dans la liste des flots" 
proteges, si les criteres d'admission sont satisfaits. 

7. Dispositif selon I'une des revendications 2 a 6, les donnees 
de conditions d'admissibilite comportant : 
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une valeur de debit, dit debit equitable et qui est une 
mesure du debit que realiserait un flot de donnees qui aurait toujours 
des paquets a emettre, 

une valeur de charge prioritaire, qui est la somme de la 
longueur des paquets prioritaires, transmis dans un certain intervalle, 
divisee par la duree de cet intervalle. 

8. Dispositif selon I'une des revendications 1 a 7, les moyens 
d'ordonnancement ordonnant comme prioritaires, dans la file d'attente, 
les flots ne presentant pas de paquets deja positionnes en file d'attente 
et comme non prioritaires les flots pour lesquels il existe au moins un 
paquet en attente dans la file d'attente. 

9. Dispositif selon I'une des revendications 1 a 8, les moyens 
d'ordonnancement ordonnant les paquets dans une file d'attente de 
type PIFO. 

10. Dispositif selon la revendication 9, un pointeur P identifiant 
le dernier des paquets prioritaires a la tete de la file. 

11. Dispositif selon la revendication 10, mettant en outre en 
oeuvre une liste de flots contenant I'identificateur de flots pour lesquels 
il existe au moins un paquet en attente, une estampille permettant 
I'ordonnancement des paquets du flot. 

12. Dispositif selon la revendication 11, comportant en outre 
des moyens de mesure de congestion. 

13. Dispositif selon la revendication 12, les mesures de 
congestion etant realisees en fonction d'une donnee de temps actuel, 
d'un nombre d'octets de paquets prioritaires transmis pendant un 
intervalle de mesure courant, et d'un nombre d'octets qu'auraient pu 
emettre un flot fictif dans ledit intervalle de mesure courant. 

14. Dispositif selon I'une des revendications 9 a 13, 
comportant des moyens pour determiner si la file PIFO est vide, ou pas. 
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15. Dispositif selon I'une des revendications precedentes, 
comportant en outre des moyens de discrimination pour distinguer des 
classes de service. 

16. Dispositif selon I'une quelconque des revendications 
precedentes, dans iequel les flots sont identifies par une fonction, de 
type « hash », d'attributs d'adresse. 

17. Procede de traitement de paquets (20) des flots sur un 
lien de reseau, comportant une etape d'ordonnancement, pour 
ordonner les paquets admis dans une file d'attente, selon un algorithme 
de partage equitable avec priorite. 

18. Procede selon la revendication 17, comportant en outre 
une etape de controle d'admission pour controler I'admission desdits 
paquets dans un dispositif de traitement desdits paquets (20), selon des 
criteres dits criteres d'admission. 

19. Procede selon la revendication 18, comportant en outre un 
envoi aux moyens (24) de controle d'admission des donnees (36) de 
conditions d'admissibilite. 

20. Procede selon la revendication 19, I'etape de controle 
d'admission comportant une interrogation, pour chaque paquet entrant, 
d'une liste (30) de flots dits proteges. 

21. Procede selon la revendication 20, les flots pour lesquels le 
temps ecoule depuis le dernier paquet recu depasse une valeur seuil 
etant effaces de la liste (30) de flots proteges. 

22. Procede selon la revendication 20 ou 21, comportant, 
lorsqu'un paquet appartient a un flot qui n'est pas dans la liste des flots 
proteges, une etape pour determiner si les criteres d'admission sont 
satisfaits. 
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23. Precede selon I'une des revendications 19 a 22, les 
donnees de conditions d'admissibilite comportant : 

une valeur de debit, dit debit equitable et qui est une 
mesure du debit que realiserait un flot de donnees qui aurait toujours 
5 des paquets a emettre, 

une valeur de charge prioritaire, qui est la somme de la 
longueur des paquets prioritaires, transmis dans un certain intervalle, 
divisee par la duree de cet intervalle. 

10 24. Procede selon Tune des revendications 19 a 23, I'etape 

d'ordonnancement ordonnant comme prioritaires, dans la file d'attente, 
les flots ne presentant pas de paquets deja positionnes en file d'attente 
et comme non prioritaires les flots pour lesquels il existe au moins un 
paquet en attente dans la file d'attente. 

15 

25. Procede selon Tune des revendications 21 a 24, les 
moyens d'ordonnancement ordonnant les paquets dans une file 
d'attente de type PIFO. 

20 26. Procede selon la revendication 25, un pointeur P identifiant 

le dernier des paquets prioritaires a la tete de la file. 

27. Procede selon la revendication 26, mettant en outre en 
oeuvre une liste de flots contenant I'identificateur des flots pour lesquels 

25 il existe au moins un paquet en attente, une estampille permettant 
I'ordonnancement des paquets du flot. 

28. Procede selon la revendication 27, comportant en outre 
une mesure de congestion. 

30 

29. Dispositif selon la revendication 28, les mesures de 
congestion etant realisees en fonction d'une donnee de temps actuel, 
d'un nombre d'octets de paquets prioritaires transmis pendant un 
intervalle de mesure courant, et d'un nombre d'octets qu'auraient pu 

35 emettre un flot fictif dans ledit intervalle de mesure courant. 
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30. Procede selon I'une des revendications 25 a 29, 
comportant une etape pour determiner si la file PIFO est vide, ou pas. 

31. Procede selon I'une des revendications 17 a 30, un signal 
relatif a la perte de paquets etant envoye a un utilisateur. 

32. Procede selon I'une des revendications 17 a 30, 
comportant en outre une discrimination entre des classes de service. 

33. Procede selon I'une des revendications 17 a 32, dans 
lequel le partage de charge des flots sur plusieurs liens est effe'ctue a 
I'aide d'une fonction des attributs d'adresse incluant la partie fibre de 
I'identificateur de flots. 
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Ddbut = Arrives 
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push in{ packet, flow jtimejsiamp) 
flowjimejstamp += L 
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ajouter idemificateur a Jiow_list avec 
restampille: 

flowjtimejstamp^virtualjtime + /, 

push {packet, virtual _time) a la 
position /* 

modifier P pour pointer sur packet 
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priority Jjyies 4= £ 
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Debut = Fin d'emission 

d'un paquet \ 50 
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next_time_stamp = cstampille 
du procham paquet a servir 
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EfFacer tous Ies flots de 

flowjist 

/ > = z^ro 
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silence Jiag = VRAl 
silence jilari - local jtime 
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virtual Jtime - nexi_timejstamp 
Effacer dejlowjist les flots tels que : 
flow_time_stamp < virtual _ti me 
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tous les time_interval CP faire 
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obtenir valeur du compteur priority Jbytes 
charge_prioritaire = (priority Jbytes - 
priority Jbytes_old) *8/ timeJntervaljCP 
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priority_bytes_old = priority kbytes 
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tous Ies time interval DE faire 
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obtenir valeurs de silence_time y 


virtuaUime et silence Jlag 
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ra/e/ = (silence Jime - 
silencejtime_old) I timeJntervalJ&E 
* debit du lien 
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ratei = {(silence jtime- 
silence Jtime _old) + (local_time - 
silence_start)) / timeJnterval__DE 
* debit du lien 

silence jstart = local jtime 
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ra/e2 = C virtual Jtime -virtual jime_old) x8/ 
timeJntervalJDE 
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silence Jimejjld ~ silence Jime 
virtual jtime __old = virtual Jime 
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